The padded shape of the next section's input chunk was being used, which
is incorrect from the perspective of the order of operations that occur
when setting up a section's source and sink in `_setup_source_sink()` in
the task runner. Instead, it should be the padded shape of the current
section's input chunk.

…culation

This is purely for the sake of making the order of the chunk size
calculations in `determine_store_backing()` match the order of the
allocations that would occur during the setup + processing of a section.

For the last section:
- the input chunk's backing (RAM or hdf5 file) is purely determined by
  the output of the previous section
- the output chunk is not written anywhere (the dummy sink simply
  discards the blocks given to it)

Furthermore, the dummy sink doesn't take a type of backing as a
parameter (and if it did, it's unclear what it could do with that
information, given that the dummy sink simply discards the input data).

Therefore, there's no need to have any calculation of the backing of the
store for the last section's writing.

Due to the previous commit, there is now only one dataset store backing
calculator function that needs a reduction operation performed, so there
is no need to have a generic way to produce a decorator that can perform
the reduction on the result of different functions.